A well designed user interface employs both content and presentation (or “style”) elements to effectively make a point or to lead a user to relevant information. Designers traditionally draw upon standard toolkits when implementing their presentation choices. For example, in a visual user interface, a designer emphasizes the presentation of some content, e.g., synopses of news articles, by selecting an element from the toolkit that enlarges the content's font or that presents it in contrasting colors. Toolkits provide similar techniques for audio user interfaces where, for example, article titles are spoken more loudly and slowly than article contents.
Within a standard toolkit, the set of presentation elements is fixed. This fixed set provides many advantages. Interface users are already familiar with such standard presentation elements as a window, a drop-down menu, and a pushbutton. While some of these elements serve mostly to frame other elements, users expect some elements to be “active”: to invoke a function when selected. Because the set of elements in the toolkit is fixed for traditional user interfaces, a designer is assured that each element has been carefully developed by the provider of the toolkit. Each element in the toolkit is given a coherent set of properties, the properties are provided with meaningful default values, and the properties interact in a rational manner. For example, a pushbutton element typically has the properties of (among many others) (1) a color and (2) an action invoked when the pushbutton is selected by a user. These properties interact rationally: The pushbutton changes color from its default blue to purple to show that it has been selected. Because of the careful development standing behind a standard toolkit, an interface designer can focus his attention on certain aspects of the interface knowing that other aspects will be cared for in a rational manner by the toolkit.
Valuable as they have proven to be, standard toolkits limit an interface designer. “Extensible” toolkits have been developed to allow designers to go far beyond what is achievable by the fixed set of presentation elements in a standard toolkit. Using an extensible toolkit, a designer creates new presentation elements. The new elements can have new properties and new actions and can interact in new ways with other elements. The designer combines newly created elements with existing elements from a standard toolkit to implement his vision of a user interface.
Extensible toolkits, however, jeopardize several of the advantages of the standard toolkit. An extensible toolkit, by definition, has no one toolkit provider: Every designer can create new presentation elements. A designer might fail to account for all possible situations in which his new element can be used. Properties of the element can have undefined values in some situations, and the values of the properties might make no sense in other situations. Even if one new element is internally consistent in all situations, the potential of having many designers provide elements to a single user interface invites coordination problems. If two elements attempt to define a property of the user interface, their individual settings might conflict in ambiguous ways. In short, new elements might not work as planned, and even if they do, they might interact in unplanned and unfortunate ways with other new elements and with existing elements taken from a standard, non-extensible toolkit.
A related danger of extensible toolkits concerns “themes.” In a carefully designed user interface, presentation property values, each possibly unimportant in itself, are chosen to work together to make the interface into a unified and coherent whole. The set of these choices is called a “theme” for the user interface. For example, a “system” theme is when an operating system provider consistently uses a complementary pallet of colors and fonts so that a user can immediately know that a particular interface is provided by the system. An example of a “branded application” theme is when the producer of a large software package presents interfaces with a common theme both to emphasize that the products in the package are meant to work together and to distinguish the software package from a competitor's package and from the operating system. In another example, a user can select an “accessibility” theme in which the visual elements of a user interface are presented in a manner more easily read (e.g., with a larger font or with more strongly contrasting colors). A coherent interface theme greatly helps a user in logically grouping information and greatly reduces the information overload present in many modern computing environments. However, interface coherence is not readily achieved when designers are free to use an extensible interface. The designer might develop presentation elements that clash with an existing theme or that neglect to account for a user's theme selection.
One solution to the problems introduced by the flexibility of extensible interface toolkits is to enforce a rigorous development and test cycle on each new presentation element. Of course, such rigor would negate much of the incentive for using an extensible toolkit: A designer uses an extensible toolkit in order to concentrate on unique aspects of new presentation elements without having to devote the bulk of development time to checking that each new element complies with all the mundane necessities of creating a unified interface.